chore(beta): merge master into releases/v3-beta - #5818
Merged
Conversation
nightly-release-v3, publish-npm, auto-changelog-v3 and changelog-v3 had no repository guard, so any fork with Actions enabled runs them against its own default branch. On a fork whose master is a PR head (#5462) this keeps committing fork-generated release bumps, npm version bumps and typedoc output (with fork source links) straight into the open PR. Guard the jobs with github.repository == 'wailsapp/wails', matching weekly-release-v2 and generate-sponsor-image. Co-authored-by: taliesin-ai <lea.anthony@gmail.com>
) (#5684) fix(v3/windows): add !server build constraint to Windows GUI files (#5680) Building a v3 project with the `server` tag on Windows failed with "redeclared" symbol errors and undefined references in pkg/application. The Windows platform GUI files were tagged `//go:build windows` without `!server`, so under `-tags server` they compiled alongside the headless `*_server.go` files and clashed. The macOS and Linux equivalents already carry `!server`; this brings Windows into line. logger_dev_windows.go is intentionally left as-is: server builds need DefaultLogger, and on Windows that file is its only provider (the generic logger_dev.go is constrained to !windows). NewIconFromResource is moved out of webview_window_windows.go into a new server-safe icon_windows.go so the notifications service still compiles under -tags server on Windows, matching macOS/Linux. Fixes #5680 Co-authored-by: Lea Anthony <lea.anthony@gmail.com>
…PRs (#5759) * ci: treat the bundled runtime as an internal build product The files in v3/internal/assetserver/bundledassets are go:embed'ed into every Wails v3 app, and minified JS cannot be reviewed by eye — a PR supplying its own bundle bytes is a malware vector. - Pin esbuild to 0.28.1 in the runtime Taskfile (npx esbuild@latest made byte-for-byte verification impossible) and expose a public runtime:build:assets task that rebuilds only the embedded bundles. - Add a Verify Runtime Assets check on every PR: when bundledassets or runtime source changed, hermetically rebuild from the PR's source and fail unless the committed bundles match byte-for-byte. Runs with a read-only token and no secrets, and self-skips on unrelated PRs so it can be made a required status check. - Watch bundledassets in publish-npm so any bundle bytes that land on master are overwritten by a trusted source-derived rebuild. - Resync the committed bundles with master's source: rebuilding revealed they were already stale (missing DateFromTime and the mac:WebViewWebContentProcessDidTerminate event present in src/) — exactly the drift this check is meant to catch. * ci: install esbuild via the lockfile instead of npx task runs build:debug and build:production as concurrent deps; two simultaneous 'npx esbuild@0.28.1' invocations race installing into the npx cache on a cold runner and one dies (seen on the JS Tests job). Pin esbuild as an exact devDependency and call the npm-ci-installed binary: one install, no build-time network fetch, and the version now lives in package-lock.json where npm ci enforces it. * Make esbuild tasks self-install deps and share the binary path Review feedback: build:debug/build:production invoked the local esbuild binary but nothing guaranteed node_modules existed, so a bare 'task runtime:build:assets' failed without a prior npm install. Both tasks now dep on install-deps, which gets 'run: once' so the two parallel builds don't race concurrent npm installs. The duplicated binary path moves into an ESBUILD var. --------- Co-authored-by: taliesin-ai <lea.anthony@gmail.com>
…of stringified JSON (#5690) * fix(bindings): returned error parsed as text instead of json * chore: updated UNRELEASED_CHANGELOG with PR number * fix(runtime): use error types as supplied by the backend for calls * fix(runtime): unbreak the public Call API * docs(v3): document typed binding call errors and structured error data Expand the Error Handling section of the method bindings docs to cover the new behaviour from #5690: failed calls reject with TypeError, RuntimeError or Error based on the error kind reported by the backend, with the Go error message on .message and the serialised Go error on .cause. Add a section on returning custom error types and customising serialisation with ServiceOptions.MarshalError. * chore(runtime): regenerate bundled runtime assets The bundled runtime is verified against a clean rebuild of the runtime source by CI, so the calls/runtime changes in this PR need the regenerated bundles committed alongside them. Built with npm ci + task runtime:build:assets per .github/workflows/verify-runtime-assets.yml. --------- Co-authored-by: taliesin-ai <lea.anthony@gmail.com>
…GND (#5687) GetClientRect can return nil during minimise/restore transitions; passing that to FillRect crashes. Guard before painting the solid background. Salvaged from #5636 (reported by @sinspired); the rest of that PR was superseded by #5596/#5616. Co-authored-by: Lea Anthony <lea.anthony@gmail.com>
…ling (#5762) master regularly moves while publish-npm.yml runs (nightly release and auto-changelog commits), so the bare 'git push' of the version bump was rejected with non-fast-forward and the job died before reaching 'npm publish'. Every run since 2026-06-29 failed this way, leaving @wailsio/runtime stale on npm at 3.0.0-alpha.95 while master's runtime source moved on - and every fresh 'wails3 init' pulls that stale package. Rebase onto current master and retry (5 attempts, backoff) before giving up. A genuine rebase conflict still fails the job loudly, and the publish step still only runs after the bump commit is safely on master. Co-authored-by: taliesin-ai <lea.anthony@gmail.com>
Automated weekly v2 release.
… v3 commands (#5763) The FAQ predated much of current v3 and had drifted badly: - Platform support said Windows 7+, macOS 10.13+ and Linux GTK3. Now matches the installation docs: Windows 10/11 (WebView2, AMD64/ARM64), macOS 10.15+/11+ (deploy target 10.13+), Linux GTK4 + WebKitGTK 6.0 default with the legacy gtk3 tag option, iOS/Android experimental, plus the server build. - Build answers used v2-style commands that do not exist in v3 (wails3 build -platform ..., manual -ldflags advice). Replaced with the real commands from the build guides (wails3 build GOOS=..., wails3 task darwin:build:universal, wails3 package) and a note that production defaults already strip binaries. - Removed the Electron comparison table in favour of stating what Wails does well on its own terms. - Every API snippet is now verified against v3 source and examples (GreetService bindings import, Events.On, app.Dialog.OpenFile chain, app.SystemTray.New) and every internal link resolves to an existing page. - Added the questions new users actually ask: prerequisites, wails3 doctor as the first troubleshooting step, build-failure checklist, how to report a bug. - Softened the production-readiness answer to point at the status page instead of overpromising. Co-authored-by: taliesin-ai <lea.anthony@gmail.com>
… FAQ with accurate platform support and verified v3 commands
…auto-labelers (#5754) * chore(.github): accept v3 bug reports, add triage dropdowns, refresh templates - bug_report.yml: remove the 'no v3 bug reports' banner (v3 bug reports are accepted), add required 'Wails version family' (v3/v2) and 'Operating System' dropdowns, ask for wails3 doctor output (wails doctor for v2), fix v2-era links and mark the v2 binding tests reference as v2-specific alongside the v3 generator path - feature_request.yml: replace the stale Wails v1 notice with the discussion-first note (Discord / GitHub Discussions), matching CONTRIBUTING.md - documentation.yml: point the contribution guidelines link at https://v3.wails.io/contributing/ - config.yml: disable blank issues, align the Discord invite with CONTRIBUTING.md - file-labeler.yml: convert to the actions/labeler v5 configuration format - delete legacy Probot .github/stale.yml (superseded by workflows/stale-issues.yml using actions/stale@v9) - add CODE_OF_CONDUCT.md (Contributor Covenant v2.1) * ci: wire up issue and PR auto-labelers Consumes the previously orphaned .github/issue-labeler.yml (github/issue-labeler@v3.4, non-versioned regex format) and .github/file-labeler.yml (actions/labeler@v5) configs. * docs: point enhancement guidance at the WEP process The Wails Enhancement Proposal process (v3/wep) was not referenced anywhere contributors actually look. Reference it from the feature request template, CONTRIBUTING.md and the v3 docs site (contributing page gets a step-by-step summary, feedback page a pointer). Also fixes the stale feedback-guide link in CONTRIBUTING.md (/getting-started/feedback/ -> /feedback/). * chore: align Code of Conduct contact with the published site CoC The v2 website has published a Contributor Covenant CoC at wails.io/coc with coc@wails.io as the enforcement contact; use the same address in the repo-level file. * docs: make GitHub Discussions the official venue for WEP discussion Proposals are discussed in the Enhancement Proposals category on GitHub Discussions. Discord remains available for informal chat but is no longer the primary venue. Adds an explicit discuss-first step to the WEP README's Idea Initiation section. * docs(wep): add index, statuses, numbering and platform section to the WEP process Implements the process improvements agreed with the maintainer: - WEP Index table in the README (number, title, status, discussion, implementation) with documented status values - Metadata header in the template (number, status, discussion link, implementor) and a Platform Considerations section - 'Do I Need a WEP?' section defining when a proposal is required - Support is now measured by upvotes on the Enhancement Proposals discussion rather than thumbs-ups on a draft PR - Decisions recorded in a standard comment format; rejected proposals stay findable via the index - Accepted proposals not started within 3 months become up for grabs - Migrated the existing proposal as WEP 0001 (dir renamed to 0001-titlebar-buttons, header added, status Implemented via #3508) * docs(wep): the WEP PR is the single discussion venue Per maintainer decision: proposals are discussed on the WEP PR itself (comments for feedback, thumbs-up reactions for support), not in a separate discussion thread. Pre-proposal ideas can optionally be floated in the Ideas category on GitHub Discussions or on Discord. Index column Discussion renamed to Proposal. --------- Co-authored-by: taliesin-ai <lea.anthony@gmail.com>
…ting (#5761) * fix(v3/windows): keep host-owned scale under visual hosting #5734 re-enabled WebView2 automatic monitor-scale detection (ShouldDetectMonitorScaleChanges) unconditionally to fix the mixed-DPI GPU-process crash. That is correct for the default windowed (HWND-child) hosting mode, but wrong under UseVisualHosting (COREWEBVIEW2_HOSTING_MODE_WINDOW_TO_VISUAL): the content is a DirectComposition visual decoupled from the child HWND that automatic detection tracks, so on a mixed-DPI monitor cross detection reads the wrong monitor and settles the visual on a stale rasterization scale -- the whole UI renders shrunk (small fonts) until something forces a re-layout. Gate the detection-enable on hosting mode: - windowed: enable detection (unchanged; keeps #5734's crash fix) - visual hosting: explicitly disable detection so the host owns the scale via resyncWebviewRasterizationScale (monitorScaleDetectionOn stays false). The module leaves detection at its platform default (enabled), so visual hosting must disable it explicitly -- merely skipping the enable would leave both Edge's detection and the host resync writing the scale (the two-writer race #5734 targets). Host-owned scale is reliable now that the by-value PutRasterizationScale bug (#5701) is fixed, and is the documented contract (WebView2Feedback #3665: detection-off is correct when the host puts the scale on every change). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(v3/windows): derive monitorScaleDetectionOn from actual controller state Query GetShouldDetectMonitorScaleChanges after the Put and set the single-writer flag from the controller's real state, not from the value requested. A failed PutShouldDetectMonitorScaleChanges could leave detection at its platform default (enabled) while monitorScaleDetectionOn stayed false, so resyncWebviewRasterizationScale would keep writing PutRasterizationScale concurrently with Edge — the two-writer scale(0,0) race this change removes. If the query itself fails, assume detection may be on and stand the host resync down. Addresses review feedback on #5761. --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: Lea Anthony <lea.anthony@gmail.com>
… host-owned rasterization scale under visual hosting
…egions (#5462) * feat(windows): add support for custom hit-test logic for non-client regions on Windows * fix(windows): address review comments * refactor: simplify non-client hit test handling logic * fix: remove handling for non-client right mouse button events * feat(windows): add cursor handling * feat(windows): handle right-click on window caption to display the system menu * fix(windows): enable non-client region tracking only is the feature is enabled * fix(windows): preserve native hover state for non-client buttons * fix(windows): address review comments * fix(runtime): rename app region css tracking internals * chore(windows): document non-client hit test ordering * feat(runtime): add runtime-config-ready event to improve initialization consistency * feat(windows): document `NonClientRegionSupport` and `WebView2CompositionHosting` options with examples and video * docs: correct video asset path in frameless windows documentation * docs: clarify `WebView2CompositionHosting` experimental status * docs: fix alignment issue in `WebView2CompositionHosting` example * docs: clarify Snap Layouts behavior and add reference to native non-client regions * docs(windows): replace `--wails-app-region` with `--wails-non-client-region` in examples and descriptions * fix(runtime): ensure runtime initialization checks for DOM environment * [skip ci] Publish @wailsio/runtime v3.0.0-alpha.96 * fix(windows): add `extendFrameIntoClientArea` helper for improved frame extension logic * fix(windows): clarify 32-bit API limitations and retain 64-bit `SetWindowLongPtrW`/`GetWindowLongPtrW` usage * fix(windows): handle `WM_SETCURSOR` with `compositionCursor` to ensure correct cursor display in client area * feat(webview2): add support for `ICoreWebView2NavigationStartingEventHandler` and navigation starting event handling * fix(webview2): add fallback to HWND controller when composition hosting fails and implement resource cleanup * fix(windows): use DPI-aware system metrics for non-client area calculations and remove hardcoded resize border fields * fix(webview2): improve DPI handling for composition-hosted and HWND-hosted WebViews, ensure correct rasterization scale updates * fix(windows): track mouse leave events in non-client and client areas to improve input handling * fix(runtime): add comment to clarify * [skip ci] Publish @wailsio/runtime v3.0.0-alpha.97 * fix(windows): remove duplicate non-client state * chore(v3): bump webview2 to v1.0.24 * chore(v3): bump to v3.0.0-alpha2.114 and update changelog [skip ci] * [skip ci] Publish @wailsio/runtime v3.0.0-alpha.96 * chore(v3): bump to v3.0.0-alpha2.114 and update changelog [skip ci] * revert: drop fork-CI artifacts (runtime alpha.96 bump + typedoc regen, fork-minted alpha2.114 release) These were committed to this branch by the fork's own GitHub Actions (publish-npm on push, nightly-release-v3 on cron), not by anyone working on the PR. The typedoc regen stamps fork source links into 90+ files and the release bump collides with upstream's real v3.0.0-alpha2.114. * fix(runtime): append scanned elements without spreading the NodeList Spreading document.body.querySelectorAll("*") into push() passes every element as a call argument, which overflows the engine's argument limit on very large documents. Reported by Copilot review. --------- Co-authored-by: GitHub Actions <github-actions@github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: taliesin-ai <lea.anthony@gmail.com>
…pport for custom hit-test logic for non-client regions
After the webview2 fold (#5711) the workspace covered a single module, ./v3, and every CI workflow already sets GOWORK=off, so it only affected local development. There it shadowed the standalone example modules nested under v3/ and forced CI to run `go work use .` on generated template projects. - delete go.work and go.work.sum - drop the go.work path filters, cache keys and the `go work use .` step from the v3 build and cross-compile workflows - also drop the webview2/** filters and webview2/go.sum cache entries, dead since the module was folded into v3/internal/webview2 - gitignore go.work/go.work.sum so local workspaces stay local
…leFileDrop Pass mouse events through to WKWebView when EnableFileDrop:true
release-v3.yml was added in #5318 and has never executed: every alpha has shipped through nightly-release-v3.yml. Reviewing it before the beta turns up four things that would each surface as a failed or misleading release. The largest: none of the six Apple secrets it reads (APPLE_SIGNING_CERT, APPLE_CERT_PASSWORD, APPLE_SIGNING_IDENTITY, APPLE_NOTARIZE_USER, APPLE_NOTARIZE_PASSWORD, APPLE_TEAM_ID) exist on the repository. On the first real run the macOS job would fail inside `security import` after three platforms had already built, the release job would never run, and nothing would be published. Changes: - New preflight job that fails in seconds rather than ten minutes in. It resolves the tag for both trigger paths, checks out that tag, and verifies v3/internal/version/version.txt matches it. version.txt is embedded, so a mismatch ships a binary that misreports its own version with no error at all. - Preflight also reports exactly which Apple secrets are missing, and either stops or, with the new allow_unsigned_macos input, continues with the signing and notarization steps skipped. No silent downgrade either way. - Publish SHA256SUMS alongside the binaries. Users currently have no way to verify a download. - Attest build provenance for every binary. The npm package already ships provenance; the binaries lagging behind it is a gap users can see. - New draft input, so the whole path can be rehearsed end to end and the resulting release deleted without ever publishing anything. The build jobs now take their checkout ref from preflight's resolved tag, so all three platforms provably build the same verified source. Verified: actionlint clean; the version-guard, missing-secret detection and checksum generation logic each exercised locally under bash -eo pipefail. Not exercised in CI, because doing that means creating a tag and a release. Claude-Session: https://claude.ai/code/session_01FigQqUQbNu9ngE4a2CSNm8 Co-authored-by: taliesin-ai <lea.anthony@gmail.com>
The beta branch had drifted 31 commits behind master, which means everything landing on master since — including the go.work removal and the release workflow hardening — was absent from the branch the beta will actually be cut from. Drift like that is only ever discovered at the worst moment. Two conflicts, both resolved in favour of the beta branch, which is the point of the branch: - v3/internal/version/version.txt keeps v3.0.0-beta.0 rather than master's v3.0.0-alpha2.117. - The FAQ production-readiness answer keeps the beta wording rather than master's "active pre-release" phrasing. Verified: no conflict markers remain; `go build ./...` in v3 behaves identically to master (the examples/ failures are pre-existing on both, not introduced here); the beta wording in faq.mdx and status.mdx survived; go.work is correctly absent after the merge. Claude-Session: https://claude.ai/code/session_01FigQqUQbNu9ngE4a2CSNm8
Contributor
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. 🗂️ Base branches to auto review (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
Documentation
leaanthony
approved these changes
Jul 26, 2026
leaanthony
left a comment
leaanthony
left a comment
Member
There was a problem hiding this comment.
Keeping the beta branch 31 commits behind master was the real risk here — the branch we cut the beta from was missing the go.work removal and the release hardening. Both conflict resolutions are right: version.txt stays at beta.0 and the FAQ keeps the beta wording, which is what the branch exists for.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
releases/v3-betahad drifted 31 commits behind master. Everything landing on master since — thego.workremoval (#5814), the release workflow hardening (#5815), the crash fixes going in now — was absent from the branch the beta will actually be cut from. That kind of drift is only ever discovered at the worst possible moment.Base is
releases/v3-beta, not master. Nothing here goes near master, and nothing is published.Conflicts, both resolved in favour of the beta branch
v3/internal/version/version.txtkeepsv3.0.0-beta.0rather than master'sv3.0.0-alpha2.117.Verification
faq.mdxandstatus.mdxsurvived the merge.go build ./...in v3 behaves identically to master — theexamples/failures are pre-existing on both, not introduced here. (Worth a separate look at some point:go build ./...fromv3/has been failing on master for those example packages, even though CI'stask test:examplespasses.)go.workcorrectly absent after the merge.What this branch already carries
The beta prep that was done earlier: FAQ rewritten with verified commands and platform support, docs wording promoted from alpha to beta,
version.txtatv3.0.0-beta.0, SECURITY.md supported-versions, channel-aware release-notes and changelog validation, and nightly change-detection extended to beta/rc tags.